Cloning a project

• Clone is a Git feature that allows a user to make a copy of a repository, including all the associated metadata on their computer so they can work on it.

1. To do this you need to the URL of the repo you are trying to clone, and a location you want to put the cloned folder

• Click on the green button labelled ‘Code’
• Click on ‘Open with GitHub Desktop’ or copy the url

Cloning a project

• Clone is a Git feature that allows a user to make a copy of a repository, including all the associated metadata on their computer so they can work on it.

2. Open GitHub Desktop and paste the URL of the repository on GitHub populated.

3. Choose where you would like the repository to be cloned to on your computer (needs an empty folder)

4. Click ‘Clone’

Cloning a project

If an update is made, then all you need to do is resynchronise your local repo with the GitHub version

Branching strategies

Branching strategies

This week we are going to learn how to create a branch and make changes to it, then integrate this branch back into the main branch. This is particularly helpful when working collaboratively.

• In Git, a branch represents a distinct version of the main repository, serving as a snapshot of your changes.

• When implementing new features or addressing issues, creating a new branch is the practice to isolate your modifications. 

• When the work is complete, a branch can be merged with the main project. 

Creating a new branch

Lets start a simple example by creating a new repo.

Creating a new branch

Lets start a simple example by creating a new repo.

• We begin with a single commit with the following content

Creating a new branch

• Now commit this change to git

Creating a new branch

• Next, let’s create a branch named shout based on this commit.

  • You do this be going to the main menu and selecting Branch > New Branch

Working on a branch

Lets modify the file by adding an explanation mark and commit the change!

• Check the status of our shout branch:

Working on a branch

Our new changes appear on the new branch of our local repo.

• Now we have made our change, we want to merge it back into the main branch

Merging a branch to main

1. switch back to the main branch

Merging a branch to main

2. start the ‘merge’

Merging a branch to main

3. choose the branch that we want to merge back in (i.e., shout)

Merging a branch to main

4. check that the version of our file in the main branch now has the exclamation mark

Merging a branch to main

5. delete shout branch

Merging a branch to main

Our current (local) work flow:

• Notice that the rejoining of the branches themselves then becomes a commit on the main branch, as this is the one we are updating.

A more complex example

• A slightly more complex situation occurs when we try to make change to two branches and then merge

• Let’s create a new branch converting the ! to a ?

A more complex example

• Say we then update the file on question and get the following

• Switching back to main then causes problems if you don’t commit your changes first!

• If we switch branches without committing first will make us lose our local changes.

A more complex example

If we want to switch a branch before committing our changes the following dialog will appear:

GitHub Desktop offers us two options:

• Leave my changes on question allows us to stash the changes (“save for later” kind of thing) and come back to the branch later and apply the stash.

• Bring my changes to main automates the process of stashing the changes, switching to the desired branch, and applying the stash.

A more complex example

If we Bring my changes to main, this will automatically bring forward the changes we made in question to main.

• Now that we are on main, we only need to commit these changes:

Recap

Lets re-cap what we have done so far.

1. First, we created a example.md file in our main branch.

Recap

Lets re-cap what we have done so far.

2. Then we created a shout branch and added an exclamation mark

Recap

Lets re-cap what we have done so far.

3. We merged the shout branch into main

Recap

Lets re-cap what we have done so far.

4. Create a question branch and changed the exclamation mark for a question mark

Recap

Lets re-cap what we have done so far.

5. Add a second line to our file on the question branch without commit it. (This is equivalent to having unsaved changes in our file - see how our diagram has not changed)

Recap

Lets re-cap what we have done so far.

6. Merge the question branch into main while bringing my changes to main

Recap

Lets re-cap what we have done so far.

7. Now we save this changes into main (i.e., commit)

Recap

If you follow these steps through, the your local Git should look like something this:

Then, you can push this into GitHub and somebody else can pull these changes to their own machine.

Merge Conflicts

In the last examples above we created a branch, made some changes and then integrated back into main.

However, what happens if you make a change to a line in a file on one branch, then you (or someone else) changes the same line of the same file on a different branch, what should Git do when you want to merge?

This is a so-called merge conflict.

Merge Conflicts

Suppose we create a new branch called capitalise and change the file to the following:

Merge Conflicts

Now imagine switch to main (or someone else is working there already) and add a full stop and commits this change before merging branches:

Merge Conflicts

We have the following:

Merge Conflicts

We have the following:

Merge Conflicts

Merge Conflicts

• At this point Git doesn’t know what to do and passes back to us to decide
• There are two approaches to deciding / fixing the problem

Merge Conflicts

We can choose to press ahead with the merge, like we did before

Merge Conflicts

GitHub Desktop will tell you which files need attention, and instruct you to open them in your preferred code editor.

The Continue Merge button is disabled! as we need to resolve the conflicts in our files.

Merge Conflicts

Open up example.md in your preferred editor and see what is happening:

• There is no automatic way of fixing this, so you will have to change it manually deleting the merge conflict syntax

• The line(s) between \(<<<<<<<\) and \(======\) here show what you already had.

• The line(s) between \(=======\) and \(>>>>>>>\) is what was introduced by the other commit (in this case from the capitalise branch).

Merge Conflicts

Let’s manually edit our file to what we want, like a mixture of both changes.

Merge Conflicts

Once the special <<<<<<<, ====== and >>>>>>> syntax is removed from our files, GitHub Desktop detects that our merge conflict has been resolved and allows us to ‘Continue Merge’:

Merge Conflicts

Once the special <<<<<<<, ====== and >>>>>>> syntax is removed from our files, GitHub Desktop detects that our merge conflict has been resolved and allows us to ‘Continue Merge’:

Merge Conflicts

This is what we have done so far:

An alternative approach

• There is a better way of doing it, that also demonstrates another use of branching
• Let’s assume we have got to the following conflict

An alternative approach

• Let’s avoid dealing with our merge conflict on main and instead fix it on goodbye
• We do this my merging main into goodbye

How?

An alternative approach

1. switch back to the goodbye branch.

An alternative approach

2. choose main as our branch to merge into goodbye

An alternative approach

3. Again, we get a conflict, but this time in goodbye

4. Manually resolve it as before, this time with some Beatles lyrics in goodbye

An alternative approach

5. GitHub Desktop has automatically detected that our merge conflict has been resolved:

An alternative approach

6. Switch back to main

An alternative approach

7. Our change can be merged without a conflict.

An alternative approach

7. Our change can be merged without a conflict.

Re-cap to solve conflicts

1. We have a merge-conflict

Re-cap to solve conflicts

1. We have a merge-conflict
2. We switch to goodbye and merge main goodbye after resolving the conflict.

Re-cap to solve conflicts

1. We have a merge-conflict
2. We switch to goodbye and merge main goodbye after resolving the conflict.
3. We switch back to main and merge back goodbye main.

Expectations for group project

• Agree on a branching workflow – this will avoid confusion!

• Example of common rules:

  • One branch, one owner: Each branch is “owned” by a single team member. This means that team members should not switch to another team member’s branch and start committing changes, unless they’ve been invited for a review (this can be done verbally).
  • Leave integration to the owner: Branches can only be merged by the owner. Possibly even after a successful review by other team members, since they’re the ones who know best when the task is complete.

• This workflow allows each person to take ownership of their task.

• We invite you to tell us about your shared rules: It shows you thought about them!

Merge and copy & paste

• Do not copy and paste whole files saved on your machine instead of solving merge conflicts.

• This is bad practice and you may end up dismissing your colleagues’ changes.